Hi Michael, On 15/02/2021 17:08, Michael Tremer wrote:
Hi,
On 12 Feb 2021, at 12:34, Adolf Belka (ipfire-dev) adolf.belka@ipfire.org wrote:
Forgot to add that I built it on my Arch Linux system with the following commands:-
./autogen.sh
/configure CFLAGS='-g -O0' --prefix=/usr --sysconfdir=/etc --libdir=/usr/lib (This was recommended to be used after autogen was run)
make
sudo make install
That’s correct.
The CFLAGS disable any optimisation (-O0) and enable generation of debugging sections (-g) which are useful for gdb.
You probably don’t need this, so you can build it without those flags.
Do you know what the process is that we could provide packages for Arch and any derivatives?
I realised that I never did anything further regarding your question about how to get fireperf into arch linux.
So more than a year later I thought I should do something about it. Arch Linux has something called the AUR (Arch User Repository) which is a community-driven repository for Arch users. It contains package descriptions (PKGBUILDs) that allow you to compile a package from source with makepkg and then install it via pacman, the package management tool in Arch.
If packages in the AUR get enough votes and there is a TU (Trusted User) willing to pick up the package then it can be moved into the community repository so users wouldn't need to do their own makepkg compiling.
I have been looking at what is involved in getting a package into the AUR and I have created a PKGBUILD file and tested it with makepkg and getting the resultant package installed with pacman. Everything worked well. I have used some arch tests to confirm that the PKGBUILD and resultant package meet the arch linux standards.
I have an account on the AUR and I have modified it to give me ssh access into the AUR and created a git repo clone for fireperf on my computer. Each package in the AUR has its own git repo in the Arch system.
The last thing to do now is to do a git push of the fireperf package from my git repo to the AUR. Before I do that I just want to confirm that you still want to go ahead with that, as it is more than a year since the idea was raised.
I will be the maintainer of the package in the AUR which basically means I will ensure it stays up to date and deal with any problems people might have with compiling and installing it, although this is a very simple package in terms of that.
Regards,
Adolf.
In general, I want to make things like libloc and fireperf available and do that as easy as possible.
-Michael
Regards,
Adolf.
On 12/02/2021 13:30, Adolf Belka (ipfire-dev) wrote:
Hi all,
I tried to also test this out on my system.
As I am not familiar with what all the command options do I just followed Daniels commands.
server: IPFire 2.25 - Core Update 153; Intel Celeron CPU J1900 @ 1.99GHz x4; I211 Gigabit Network Connection
client: Arch Linux; Intel Core i5-8400 CPU @ 2.80GHz 6 core; 1GBit nic
Server: fireperf -s -P 10000 -p 63000:630010
Client: fireperf -c <IP address> -P 1 -x -p 63000:63010 where <IP address> was replaced with the IP address of my IPFire Green connection.
I started the server fireperf and there was the table updating regularly.
I started the client and got "Could not open socket: Address family not supported by protocol" scrolling up the screen.
I looked in the log (journalctl) but there were no messages at all related to fireperf just the command being run.
Any thoughts on what I am missing to have setup or installed?
Regards,
Adolf.
On 09/02/2021 13:53, daniel.weismueller@ipfire.org wrote:
Hi guys,
today I installed fireperf on my testing IPFire and my Ubuntu PC.
server: IPFire Core 154; Intel i7 4790; Intel 82571EB/GB 1GBit Nic Client: Ubuntu 20.4; Intel i7 9700; Intel i219-V 1GBit Nic
Michael and I agreed that one more port should be opened per 5000 expected connection per second (cps)
So here my results:
Server: fireperf -s -P 10000 -p 63000:630010
Client: fireperf -c <IP address> -P 1 -x -p 63000:63010 -> ~5000 cps
fireperf -c <IP address> -P 10 -x -p 63000:63010 -> ~30000-35000 cps
fireperf -c <IP address> -P 100 -x -p 63000:63010 -> ~35000-40000 cps
fireperf -c <IP address> -P 1000 -x -p 63000:63010 -> ~40000-45000 cps
fireperf -c <IP address> -P 10000 -x -p 63000:63010 -> ~46000-48000 cps
The cpu utilization was limited to one core and increased in sync with the cps on both sides.
In my last test, the utilization was about 85-100% on the server and 75-95% on the client.
In the next days I will test our mini and post the results here.
Daniel