<commit_before>Task 1:
    1)  The system state consists of the current time, all live packets and their state,
        the state of every BS and server, and the state of the controller. For the BSs,
        servers and controller we only need to know if they are currently busy processing,
        as we assume they are always working in this section.
        Events are:
        -Packet sent from meter
        -Packet arrived at BS
        -Packet lost on the way to BS
        -Packet processed in BS
        -Packet sent from BS to C
        -Packet arrived at C
        -Packet processed in C
        -Packet sent from C to server
        -Packet arrived at server
        -Packet processed in server (success)
        
    2)  We chose to make the Base Station entity handle packet scheduling instead of
        creating many Smart Meter entities as generators. This significantly simplifies the model without an accuracy tradeoff in this situation. The diagram shows a single Base Station handling a single Smart Meter for readability, but it can apply to many Base Stations with many Smart Meters per station. The Base Station would simply send packets belonging to every attached meter before holding.

        See: diagrams/
        
    3)  my time unit is seconds
        I had to make my meters stop producing packets after pkt numeber 100000 to make the simulation terminate
        
        num_of_meters := 1000;
            pkt_total | pkt_success | pkt_failed | pkt_lt200 | pkt_dly AVERAGE/EST.ST.DV/ STD.ERR./  MINIMUM/  MAXIMUM
               100000 |       95025 |       4975 |      8711 |           0.588     0.2768.963&-004     0.110     1.167
               
        num_of_meters := 10000;
            pkt_total | pkt_success | pkt_failed | pkt_lt200 | pkt_dly AVERAGE/EST.ST.DV/ STD.ERR./  MINIMUM/  MAXIMUM
               100000 |       95025 |       4975 |        88 |          43.016    24.4567.933&-002     0.111    85.802
               
        num_of_meters := 100000;
            pkt_total | pkt_success | pkt_failed | pkt_lt200 | pkt_dly AVERAGE/EST.ST.DV/ STD.ERR./  MINIMUM/  MAXIMUM
               100000 |       95025 |       4975 |        88 |          47.508    27.3118.860&-002     0.111    94.802

        We can from the information below deduce that the bottleneck must be the servers:
        
                                  R E S O U R C E S
                                  *****************
        TITLE       /   (RE)SET/   OBS/ LIM/ MIN/ NOW/  % USAGE/ AV. WAIT/QMAX
        C                 0.000  95025    1    0    1    19.659     0.171 3136
        Servers           0.000  95025    4    0    4    97.705    11.53246212


    4)  N_s := 2;
            num_of_meters := 1000;
                pkt_total | pkt_success | pkt_failed | pkt_lt200 | pkt_dly AVERAGE/EST.ST.DV/ STD.ERR./  MINIMUM/  MAXIMUM
                   100000 |       95025 |       4975 |      8711 |           0.588     0.2768.963&-004     0.110     1.167
            
            num_of_meters := 2000;
                pkt_total | pkt_success | pkt_failed | pkt_lt200 | pkt_dly AVERAGE/EST.ST.DV/ STD.ERR./  MINIMUM/  MAXIMUM
                   100000 |       95025 |       4975 |        88 |          23.064    12.9084.187&-002     0.111    45.802
                
            num_of_meters := 4000;
                pkt_total | pkt_success | pkt_failed | pkt_lt200 | pkt_dly AVERAGE/EST.ST.DV/ STD.ERR./  MINIMUM/  MAXIMUM
                   100000 |       95025 |       4975 |        88 |          35.534    20.1176.526&-002     0.111    70.802

        
        N_s := 4;
            num_of_meters := 1000;
                pkt_total | pkt_success | pkt_failed | pkt_lt200 | pkt_dly AVERAGE/EST.ST.DV/ STD.ERR./  MINIMUM/  MAXIMUM
                   100000 |       95025 |       4975 |     18103 |           0.348     0.1384.481&-004     0.110     0.640
            
            num_of_meters := 2000;
                pkt_total | pkt_success | pkt_failed | pkt_lt200 | pkt_dly AVERAGE/EST.ST.DV/ STD.ERR./  MINIMUM/  MAXIMUM
                   100000 |       95025 |       4975 |      9118 |           0.585     0.2758.929&-004     0.110     1.128

            num_of_meters := 4000;
                pkt_total | pkt_success | pkt_failed | pkt_lt200 | pkt_dly AVERAGE/EST.ST.DV/ STD.ERR./  MINIMUM/  MAXIMUM
                   100000 |       95025 |       4975 |       182 |          11.835     6.4662.098&-002     0.111    23.457
        
    5)  Packetloss can only happen during the wireless transmission to the BR, which has a 5% chance of happening
        pkt_failed / pkt_total = 0.04975 closely resemples this in all tests.
        I believe the lack of variation is because demos doesn't seed it's psuedo random
        number generator with the system time, it simply sets the seed to 907 (line 3022 in demos.sim)
        
        *todo: more*

Task 2:
    1)  
        
    2)  
        
    3)  <commit_msg>Clean up main.sim and two lines in tasks.txt<commit_after>Task 1:
    1)  The system state consists of the current time, all live packets and their state,
        the state of every BS and server, and the state of the controller. For the BSs,
        servers and controller we only need to know if they are currently busy processing,
        as we assume they are always working in this section.
        Events are:
        -Packet sent from meter
        -Packet arrived at BS
        -Packet lost on the way to BS
        -Packet processed in BS
        -Packet sent from BS to C
        -Packet arrived at C
        -Packet processed in C
        -Packet sent from C to server
        -Packet arrived at server
        -Packet processed in server (success)
        
    2)  We chose to make the Base Station entity handle packet scheduling instead of
        creating many Smart Meter entities as generators. This significantly simplifies the model without an accuracy tradeoff in this situation. The diagram shows a single Base Station handling a single Smart Meter for readability, but it can apply to many Base Stations with many Smart Meters per station. The Base Station would simply send packets belonging to every attached meter before holding.

        See: diagrams/
        
    3)  my time unit is seconds
        I had to make my meters stop producing packets after pkt numeber 100000 to make the simulation terminate
        
        num_of_meters := 1000;
            pkt_total | pkt_success | pkt_failed | pkt_lt200 | pkt_dly AVERAGE/EST.ST.DV/ STD.ERR./  MINIMUM/  MAXIMUM
               100000 |       95025 |       4975 |      8711 |           0.588     0.2768.963&-004     0.110     1.167
               
        num_of_meters := 10000;
            pkt_total | pkt_success | pkt_failed | pkt_lt200 | pkt_dly AVERAGE/EST.ST.DV/ STD.ERR./  MINIMUM/  MAXIMUM
               100000 |       95025 |       4975 |        88 |          43.016    24.4567.933&-002     0.111    85.802
               
        num_of_meters := 100000;
            pkt_total | pkt_success | pkt_failed | pkt_lt200 | pkt_dly AVERAGE/EST.ST.DV/ STD.ERR./  MINIMUM/  MAXIMUM
               100000 |       95025 |       4975 |        88 |          47.508    27.3118.860&-002     0.111    94.802

        We can from the information below deduce that the bottleneck must be the servers:
        
                                  R E S O U R C E S
                                  *****************
        TITLE       /   (RE)SET/   OBS/ LIM/ MIN/ NOW/  % USAGE/ AV. WAIT/QMAX
        C                 0.000  95025    1    0    1    19.659     0.171 3136
        Servers           0.000  95025    4    0    4    97.705    11.53246212


    4)  server_queue :- new Res("Server", 2);
            num_of_meters := 1000;
                pkt_total | pkt_success | pkt_failed | pkt_lt200 | pkt_dly AVERAGE/EST.ST.DV/ STD.ERR./  MINIMUM/  MAXIMUM
                   100000 |       95025 |       4975 |      8711 |           0.588     0.2768.963&-004     0.110     1.167
            
            num_of_meters := 2000;
                pkt_total | pkt_success | pkt_failed | pkt_lt200 | pkt_dly AVERAGE/EST.ST.DV/ STD.ERR./  MINIMUM/  MAXIMUM
                   100000 |       95025 |       4975 |        88 |          23.064    12.9084.187&-002     0.111    45.802
                
            num_of_meters := 4000;
                pkt_total | pkt_success | pkt_failed | pkt_lt200 | pkt_dly AVERAGE/EST.ST.DV/ STD.ERR./  MINIMUM/  MAXIMUM
                   100000 |       95025 |       4975 |        88 |          35.534    20.1176.526&-002     0.111    70.802

        
        server_queue :- new Res("Server", 4);
            num_of_meters := 1000;
                pkt_total | pkt_success | pkt_failed | pkt_lt200 | pkt_dly AVERAGE/EST.ST.DV/ STD.ERR./  MINIMUM/  MAXIMUM
                   100000 |       95025 |       4975 |     18103 |           0.348     0.1384.481&-004     0.110     0.640
            
            num_of_meters := 2000;
                pkt_total | pkt_success | pkt_failed | pkt_lt200 | pkt_dly AVERAGE/EST.ST.DV/ STD.ERR./  MINIMUM/  MAXIMUM
                   100000 |       95025 |       4975 |      9118 |           0.585     0.2758.929&-004     0.110     1.128

            num_of_meters := 4000;
                pkt_total | pkt_success | pkt_failed | pkt_lt200 | pkt_dly AVERAGE/EST.ST.DV/ STD.ERR./  MINIMUM/  MAXIMUM
                   100000 |       95025 |       4975 |       182 |          11.835     6.4662.098&-002     0.111    23.457
        
    5)  Packetloss can only happen during the wireless transmission to the BR, which has a 5% chance of happening
        pkt_failed / pkt_total = 0.04975 closely resemples this in all tests.
        I believe the lack of variation is because demos doesn't seed it's psuedo random
        number generator with the system time, it simply sets the seed to 907 (line 3022 in demos.sim)
        
        *todo: more*

Task 2:
    1)  
        
    2)  
        
    3)  
{'fraction_non_alphanumeric': 0.06751477511770008, 'fraction_numerical': 0.10698186917760193, 'mean_word_length': 1.4256559766763848, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 6, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2386582', 'n_tokens_mistral': 3682, 'n_tokens_neox': 3013, 'n_words': 1009}