The debugging output is great! Thanks. I'll try that on the SAMA5D36
too.
With CONFIG_SIM_WALLTIME=y the loopback tcpblaster seems to chunk along
pretty quickly:
Sent 50 buffers: 200.0 Kb (avg 4.0 Kb) in 7823.46 Sec ( 0.0 Kb/Sec)
Received 50 buffers: 66.6 Kb (avg 1.3 Kb) in 2575.50 Sec ( 0.0
Kb/Sec)
Received 50 buffers: 66.9 Kb (avg 1.3 Kb) in 2575.50 Sec ( 0.0
Kb/Sec)
Received 50 buffers: 66.6 Kb (avg 1.3 Kb) in 2575.50 Sec ( 0.0
Kb/Sec)
Sent 50 buffers: 200.0 Kb (avg 4.0 Kb) in 7665.90 Sec ( 0.0 Kb/Sec)
Received 50 buffers: 66.6 Kb (avg 1.3 Kb) in 2499.75 Sec ( 0.0
Kb/Sec)
Received 50 buffers: 66.9 Kb (avg 1.3 Kb) in 2424.00 Sec ( 0.0
Kb/Sec)
Received 50 buffers: 66.6 Kb (avg 1.3 Kb) in 2424.00 Sec ( 0.0
Kb/Sec)
So it appears to be working fine in the simulator.
Now if I could get the simulator to network with the linux host, I could
test out non-loopback mode. I am still not sure what's wrong there.
The timing still looks really bad. Without CONFIG_NET_WALLTIME, the
simulation just runs as fast as it can, but it should still mostly
preserve fidelity in "relative" time. So, although the output is
generated fast, it is still saying it took about 2500 seconds to send
1.3 Kb at a rate of zero Kb/sec. Still looks bad to me.
So there still looks like a timing problem. I think that test
excludes about all other sources of problems except: (1) your
configuration, and (2) your Ethernet driver. Timing could still be the
culprit.
Timestamping the debug output will still be a good idea.
I also see that the configuration that was merged has a packet size of
only 296 bytes! That could also be a factor.
Feel free to improve that configurtion as needed (don't submitted debug
stuff in the configurations, debug should always be off be default).
