How to simulate what happens inside the packet buffer of a simple switch?

I'm debugging a case of UDP packets lost in a store-and-forward gigabit switch and I wanted to visualize what happens inside the switch to better understand the gist of the problem.

The scenario is simple - two bursty data streams come through 2 ports inside the switch and both want to leave it via a third port (common to both). So the switch needs to hold some data in the packet buffer for a while.

The problem is: based on my simple calculations, the buffers should be large enough to handle the case I'm examining. One data stream sends bursts of 25 kB (divided to 1514 B packets) every 1.56 ms, the other one sends bursts of 60 kB every 1 ms. Now, even a soho switch like Netgear GS105E has buffer of size 128 kB. So the simple math (25+60 < 128) tells it should work even if the streams come to ingress at the same time (given there is no other substantial traffic).

The real tests show that a lot of packets from both streams get lost on some switches (it seems to be bound to buffer size, but not only to it). In my simulation, I cannot get the buffer to overfill when set to 128 kB.

I recorded this animation for a 24 kB-sized buffer where there is the overfill. However, you can easily see that increasing the buffer just a few bytes would resolve the issue and all packets would go through.

I did a few simplifications in this simulation. All packets have the same QoS (that is also in the real case). So I left out QoS queues from the simulation and I'm treating all traffic as equally important. Next, I left out memory management of the buffer. I can imagine it is an important part of the problem, but I'd be surprised if my simplification with perfect allocations would be more than 10% wrong from the real case. I also pretend that the switch knows the frame length when it receives its first bytes so that it reserves all the needed memory on the beginning. As I could not find any documentation about the size of ingress/egress queues of the ports, I assume they are all placed in the shared packet buffer and they can take as large part of the buffer as needed (although I think the culprit may be somewhere here). I've set the processing delay of each packet to 512 ns (the propagation delay of a 64 B packet).

I'm not sure if it plays a role, but the streams consist of fragmented UDP packets (i.e. the 25 kB burst is a single UDP packet fragmented to 17 IP fragments). The second stream creates the burst as 2 or 3 20 kB UDP packets, each fragmented to 14 IP fragments.

Iperf 3.7 commands to replicate streams similar to the real ones are:

iperf3 -c sink -u -b 128M -t 600 -l 25256 --pacing-timer 1560
iperf3 -c sink -u -b 400M -t 600 -l 20k --pacing-timer 1000

Do you have any ideas what else did I forget to take into account that could cause the simulation to be so far from reality? Thank you for help!

Source code for the animation is at https://gist.github.com/peci1/a0346538acc6c289b2c6d596b184ad21 .

Here is my result table from the real experiments. Data stream one is fixed - 128 Mbps in 25 kB UDP packets each 1.56 ms. I was changing parameters of the second stream trying to find the limit where packets of the first stream will start getting lost by the switch. I was changing the -l (length) parameter specifying size of the UDP packet, and the -b (bandwidth) parameter specifying what bandwidth should these packets generate. --pacing-timer was always set to 1000 for the second stream. You can see that the D-Link and Netgear GS105 cannot cope with the 60 kB bursts at all. GS108 does much better than GS105, while it has almost the same switch chip (the same "family", just different number of ports and a bit larger buffer).

(This question has been migrated from https://networkengineering.stackexchange.com/questions/78529/how-to-simulate-what-happens-inside-the-packet-buffer-of-a-simple-switch where it was marked as off-topic).