JSBSim on RISC-V

[dpculp]

I've got JSBSim running on a RISC-V based single board computer. The SBC is the new VisionFive 2 from StarFive. It has a quad core CPU, 8 GB of memory, and runs Debian linux. The computer is not very fast. Even the Xfce desktop runs slowly, but considering how new the tech is I'm not disappointed.

The Debian image supplied by StarFive contains the gcc version 11.3.0 compiler and Python 3.10.5

I've had no trouble getting other software built for the RISC-V 64 bit platform using apt. Things like cmake, git, gnome system tools, htop, gedit.

[bcoconni]

Nice !

[dpculp]

I suspected JSBSim would run OK considering there is already a normal linux system running on the board. What I'm still not sure of is how the hardware timer compares to the timer on ARM or x86 chips. I don't have test plan for that, but I'll look into it. In the mean time I'll source a heat sink and fan before doing any stress testing.

[seanmcleod]

@dpculp out of interest, did you buy this SBC specifically for JSBSim use, or are you planning on using it for something else and just decided to check out JSBSim on it as well?

[dpculp]

@seanmcleod I originally ordered it out of general interest. AFAIK it's the first RISC-V SBC that can be used as a desktop computer. While it was on the way I wondered about JSBSim and how the hardware timer would work compared to other archs. Now that I have the board set up and have built some apps with it I realize I don't have a good way to test the timer.

Next test will be to build QtJSBSim for it. I've read on the forums that Qt has been ported to the RISC-V-64 except for the QWebEngine module. This will also be a test of SDL2 and joystick support.

[seanmcleod]

I wondered about JSBSim and how the hardware timer would work compared to other archs.

Are you referring to the timer that JSBSim makes use of from the OS for the realtime path?

jsbsim/src/JSBSim.cpp

Lines 530 to 555 in 08a3ae5

	} else { // ------------ RUNNING IN REALTIME MODE
	// "was_paused" will be true if entering this "run" loop from a paused state.
	if (was_paused) {
	initial_seconds += paused_seconds;
	was_paused = false;
	}
	current_seconds = getcurrentseconds(); // Seconds since 1 Jan 1970
	actual_elapsed_time = current_seconds - initial_seconds; // Real world elapsed seconds since start
	sim_lag_time = actual_elapsed_time - FDMExec->GetSimTime(); // How far behind sim-time is from actual
	// elapsed time.
	for (int i=0; i<(int)(sim_lag_time/frame_duration); i++) { // catch up sim time to actual elapsed time.
	result = FDMExec->Run();
	cycle_duration = getcurrentseconds() - current_seconds; // Calculate cycle duration
	current_seconds = getcurrentseconds(); // Get new current_seconds
	if (FDMExec->Holding()) break;
	}
	if (play_nice) sim_nsleep(sleep_nseconds);
	if (FDMExec->GetSimTime() >= new_five_second_value) { // Print out elapsed time every five seconds.
	cout << "Simulation elapsed time: " << FDMExec->GetSimTime() << endl;
	new_five_second_value += 5.0;
	}
	}
	} else { // Suspended

In other words getcurrentseconds() and possibly also sim_nsleep()?

jsbsim/src/JSBSim.cpp

Lines 112 to 144 in 08a3ae5

	#if defined(__BORLANDC__) || defined(_MSC_VER) || defined(__MINGW32__)
	double getcurrentseconds(void)
	{
	struct timeb tm_ptr;
	ftime(&tm_ptr);
	return tm_ptr.time + tm_ptr.millitm*0.001;
	}
	#else
	double getcurrentseconds(void)
	{
	struct timeval tval;
	struct timezone tz;
	gettimeofday(&tval, &tz);
	return (tval.tv_sec + tval.tv_usec*1e-6);
	}
	#endif
	#if defined(__BORLANDC__) || defined(_MSC_VER) || defined(__MINGW32__)
	void sim_nsleep(long nanosec)
	{
	Sleep((DWORD)(nanosec*1e-6)); // convert nanoseconds (passed in) to milliseconds for Win32.
	}
	#else
	void sim_nsleep(long nanosec)
	{
	struct timespec ts, ts1;
	ts.tv_sec = 0;
	ts.tv_nsec = nanosec;
	nanosleep(&ts, &ts1);
	}
	#endif

[bcoconni]

A bit off topic but the __BORLANDC__ flag is quite outdated 😄
May be we should get rid of it, one day ?

[dpculp]

Yes, I remember looking into timers a few years ago while writing QtJSBSim, and I saw some hardware variations, but it seems the kernel hides the differences from us by rounding. According to this: https://linux.die.net/man/7/time the newer kernels, 2.5 and 2.6 have finer resolution available.

I think I'd have to run in real time at a high refresh rate to see any difference between architectures, and even then with the new kernels there might be no difference. It's an experiment for a later time.

From the time(7) man page linked above:

`The hardware clock

Most computers have a (battery-powered) hardware clock which the kernel reads at boot time in order to initialize the software clock. For further details, see rtc(4) and hwclock(8).
The software clock, HZ, and jiffies

The accuracy of various system calls that set timeouts, (e.g., select(2), sigtimedwait(2)) and measure CPU time (e.g., getrusage(2)) is limited by the resolution of the software clock, a clock maintained by the kernel which measures time in jiffies. The size of a jiffy is determined by the value of the kernel constant HZ.
The value of HZ varies across kernel versions and hardware platforms. On i386 the situation is as follows: on kernels up to and including 2.4.x, HZ was 100, giving a jiffy value of 0.01 seconds; starting with 2.6.0, HZ was raised to 1000, giving a jiffy of 0.001 seconds. Since kernel 2.6.13, the HZ value is a kernel configuration parameter and can be 100, 250 (the default) or 1000, yielding a jiffies value of, respectively, 0.01, 0.004, or 0.001 seconds. Since kernel 2.6.20, a further frequency is available: 300, a number that divides evenly for the common video frame rates (PAL, 25 HZ; NTSC, 30 HZ).

The times(2) system call is a special case. It reports times with a granularity defined by the kernel constant USER_HZ. User-space applications can determine the value of this constant using sysconf(_SC_CLK_TCK).

High-resolution timers

Before Linux 2.6.21, the accuracy of timer and sleep system calls (see below) was also limited by the size of the jiffy.
Since Linux 2.6.21, Linux supports high-resolution timers (HRTs), optionally configurable via CONFIG_HIGH_RES_TIMERS. On a system that supports HRTs, the accuracy of sleep and timer system calls is no longer constrained by the jiffy, but instead can be as accurate as the hardware allows (microsecond accuracy is typical of modern hardware). You can determine whether high-resolution timers are supported by checking the resolution returned by a call to clock_getres(2) or looking at the "resolution" entries in /proc/timer_list.

HRTs are not supported on all hardware architectures. (Support is provided on x86, arm, and powerpc, among others.)`

[jonsberndt]

Bertrand wrote: A bit off topic but the __BORLANDC__ flag is quite outdated 😄 May be we should get rid of it, one day ? I was noticing this recently – I agree, this doesn’t really apply any more and is a minor nuisance. The flag can almost surely be removed and the code cleaned up. JB

[dpculp]

I ran a tougher test using a 500 hz integration rate, thinking the higher rate (which is also not divisible by 30) might induce a timer round-off. On both of the machines, an amd64 and a riscv64, the results after 5 minutes of a real time run are the same.

My fears of a hardware timer difference were unfounded. Or, the test isn't testing what I think it's testing.