Mesa hm2/hm2_7i96s.0: error finishing read

tommylight wrote:

rodw wrote:

rtt min/avg/max/mdev = 0.245/0.465/0.698/0.074 ms

max ping time = 0.510

Nope, max ping time 0.698.
Usually the first one or two replies are longer, then settle.
min/ avg/ max/ mdev
0.245/0.465/0.698/0.074 ms

Tommy, yses .510 is after the first slower ping.
But the point is pings are  worse than Johns and does not get an error finishing read and TMAX values are way lower...
The queston is why?

I would venture a guess at the way the driver requests interrupts to hardware, but i am not willing to go deep into that, especially since you already did a lot of work in figuring out solutions and what drivers work, so thank you for the time and effort you put into it.
Did anyone try ping with bigger frames/packets?
Pretty sure the size will mess response times quickly on the kernels with issues.
Or maybe, just maybe there is something wrong in those kernels in the way they handle UDP transport?
Ping is TCP/IP/ICMP, Mesa uses UDP if i am not mistaken, and so did Quake 3, the game. Quake had a way to switch to TCP/IP but that was laggy as hell with the limited bandwidth we had.

I don't think getting a machine to work by accdent really counts moving forward to a solution.
I have wondered about NIC parameters.
I am wondering if the hm2-eth driver can be improved to compensate. Maybe its the way we do things..

I think the issue is kernel driver related (though it may be unrelated drivers such as
video drivers)

To test ping times , you must run the test at a real time priority, and run the test for a long time, something like:

sudo chrt 99 ping -i .001 -q 10.10.10.10

For a short time, the average was 0.129. The Max is meaningless as its the first ping and no doubt is distorting the result.
Trying for a long time now.......

After 4 hours The max is still likely to be the startup command. I gusee but the average is good @ 0.129