link - probe

i finished commenting through echo_client

I commented through channel.py so it is easier to read the documentation and understand

using pytest I added a test_channel.py file that checks 3 of the functions in my code ( make_channel) adding bernoullie lost and changing GE burst lengths

FIxed readme and added to results.md

ok next I made a new plot to analyze the missed packet dealine percentage for my latency ladder and jitter runs, and we can see that all the latency ladders show a similar shape with a horizantal shift, while the jitter run has the shape of a oddpower function with an inflection point around 100ms

I made a new pythoin fiel athat created a new figure using matplotlib and this measures teh median and p99 rtt for my latency ladder, i will know add this into my results .md

So i worked on fixing or updating my plot.py with some feature. I added a title verision and fixed the y axis labeling and then adding a theoriticla value using the defintaitons of GE loss and bernoullie loss somethign we see is that int he real data we have a stair case step due to burts values being aonly integers while the therotical value using a line of best fit which is linear. here is a before and after

added sections 5-7 to resutls.md which talk about the limitations and like also talked about the py file i made yesterday

i added a new file that is supposed to check across all runs if the value in the csv matches with my decide function to check my seeds. Out of 60000 packets i only got one mismatch

I first added requiremetns.txt in my repo for people who want to re run or add onto the experiment, also made sure to include instructison to reapeat in my read me then i fixed some rounding errors in my summary.csv and alsltyu added a results.md that I have not finished yet

i used matplotlib to make a graph of my burst results. the x axis is the burst length(how many packets are lloss in a row). and the y axis is the the eprcentage of hwo many burst were greater than the k value so you obvisouly see a decleining trend because for both its much aharder from a. randopoitn for lose a lot of pacerts in a. row we see. big differen of giulbert elliot and bernouli here and the fidffernt between the two packet loss calcauation methods

So now i wokred on making anogther csv apart of anlsyze.py whiuchcounts hwo many burst were in each run, and the lenght adn fequencey of teh burst. A burst is basically how many packets were lsot in a row. so now i am gona downlaodn matpotlib to plot it and see how my data and expereiment actually works and try andundesrtand my reustls

ok i had to fix a fewt hign with my analyze.py and sumamry.csv, because it didnt trrakc lost packets or parameters of the runs so then i used enumerate and slicing, and joining to get the right parameters for each run

so over the past few days i have been working on a analyze.py python filet hat will take my csv results of the 14 trials and then basiclaly take all of it and make it into one summary obvisouly its missing late and params so i have to fix that and make a new one but I had to learn a lot and there was a lot of logic i did wrong in the beginning so im glad i wokred it out

today was long day, bsically wrote a new python file that will connect to config.py and run the server and client multiple times and ran a smoke test. learned a lot of new things like matrixes which keep all my test aswell as parsing throuhg argparse

Today I created a config.py where I can set all my parameters for my experiments I can do and used it to connect channel.py to config.py I also ran some tests of bernoulli versus elliot

researched on gilbert elliot and bernoulli package loss distrubutions and made a model to simulate that in channel.py

Today I found a bug where my client could save a reply under the wrong packet. The client grabbed whichever reply showed up first and assumed it belonged to the packet it had just sent. When a reply came back after the timeout, it got recorded as the next packet’s reply, and every packet after that was shifted by one. Nothing crashed. The data was just wrong.To prove it, I made my server hold a reply for 1.5 seconds while my timeout was 1 second. By accident, my first test delayed every packet after the 20th. The RTTs climbed from 1.5 s to 12 s, every other packet was marked lost, and the ones marked received carried an older packet’s time.The fix: every packet gets a deadline (send time + timeout), and the client keeps listening until the reply with the matching sequence number arrives or time runs out. Replies for older packets get counted as “late” and thrown away. Now the same test shows 1 lost, 1 late, and every packet after it keeps the right number. This matters because my jitter profile will produce late replies constantly, and without this fix every jitter run would have been garbage. i also added totola runtime and average packet rate

I worked on making my data from tests actually to be exported as csv files, I had to learn how to use the csv file node in python and how to make sure my files don’t get overidden each time and how to show a packet is lost then i ran some trials and saw the csv but I still need to fix some things

added file constants aswell as working through some bugs. Basically tried out a few experiments with how many packets I sent and the time in between each packet. It really changed the average dtt and also I got to see how counter worked

I added the first layer of my experimentation, a server and a client. The client sends packets of info with sequence number to the server and then sends it back to the client then prints out the number in sequence and the time of the whole trip.

created github and readme.md to start of my project also wrote more in detail why i am doing this and aswell as what I am trying to accomplish and what I am measuring, I had to spend a lot of time fixing hackatime. I Learned a lot about why packets actually get lost and how modern researchers categorize their loss and why it happens.