go test fails in qemu-riscv64

[Xunop]

What version of V2Ray are you using?

5.8.0 branch

What's your scenario of using V2Ray?

Performing go test in qemu-riscv64.

What problems have you encountered?

After following the instructions in this issue 1830, the go test has a chance of failing on my slightly more powerful desktop (Intel i5-13600k) but consistently fails on my laptop (AMD Ryzen 5 5600H). The failed tests are TestDialAndListen and TestVMessKCP.

What's your expectation?

Pass all unit tests.

Please attach your configuration here

N/A

Server configuration:

N/A

Client configuration:

N/A

Please attach error logs here

Use curl http://fars.ee/pS7F > log.txt to get go test log.

Server error log:

N/A

Client error log:

N/A

Please attach access log here

N/A

Other configurations (such as Nginx) and logs here

N/A

If V2Ray cannot start up, please attach output from --test command

N/A

If V2Ray service is abnormal, please attach journal log here

N/A

---

For TestVMessKCP, my solution is to set a 4-second delay before the execution of the testTCPConn function within the loop:

diff --git a/testing/scenarios/vmess_test.go b/testing/scenarios/vmess_test.go
index e1acd455..7dfc8466 100644
--- a/testing/scenarios/vmess_test.go
+++ b/testing/scenarios/vmess_test.go
@@ -806,6 +806,7 @@ func TestVMessKCP(t *testing.T) {
 
 	var errg errgroup.Group
 	for i := 0; i < 10; i++ {
+		time.Sleep(time.Second * 4)
 		errg.Go(testTCPConn(clientPort, 10240*1024, time.Minute*2))
 	}
 	if err := errg.Wait(); err != nil {

For TestDialAndListen, my solution is to extends the sleep duration from 500 milliseconds to 1000 milliseconds:

diff --git a/transport/internet/kcp/kcp_test.go b/transport/internet/kcp/kcp_test.go
index d10534a2..43ea9db3 100644
--- a/transport/internet/kcp/kcp_test.go
+++ b/transport/internet/kcp/kcp_test.go
@@ -77,7 +77,7 @@ func TestDialAndListen(t *testing.T) {
 	}
 
 	for i := 0; i < 60 && listener.ActiveConnections() > 0; i++ {
-		time.Sleep(500 * time.Millisecond)
+		time.Sleep(1000 * time.Millisecond)
 	}
 	if v := listener.ActiveConnections(); v != 0 {
 		t.Error("active connections: ", v)

[AkinoKaede]

This is a common problem in software engineering, low-performance device may cause unit tests to fail due to timeout.

[AkinoKaede]

This is a common problem in software engineering, low-performance device may cause unit tests to fail due to timeout.

It is true that the timeout can be increased to solve this problem, but there is no regulation on what device should be the minimum performance standard.

[Xunop]

This is a common problem in software engineering, low-performance device may cause unit tests to fail due to timeout.

It is true that the timeout can be increased to solve this problem, but there is no regulation on what device should be the minimum performance standard.

In my case, I've set different timeout values on my various computers. I've had to use longer timeouts in order to successfully pass the unit tests. If I don't run the unit tests in the qemu-riscv environment, but in the host environment, these unit tests pass very easily.

Unfortunately, I'm currently stumped on finding a more effective solution, and I apologize for not being able to provide a better suggestion at this time :(

[AkinoKaede]

This is a common problem in software engineering, low-performance device may cause unit tests to fail due to timeout.

It is true that the timeout can be increased to solve this problem, but there is no regulation on what device should be the minimum performance standard.

In my case, I've set different timeout values on my various computers. I've had to use longer timeouts in order to successfully pass the unit tests. If I don't run the unit tests in the qemu-riscv environment, but in the host environment, these unit tests pass very easily.

Unfortunately, I'm currently stumped on finding a more effective solution, and I apologize for not being able to provide a better suggestion at this time :(

I'm looking for a RISC-V development board to use as a performance benchmark.

[github-actions[bot]]

This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days