Setup new System on PI1LAP

Today I started setting up a new system. I still have an old system on the shelf
that I think is suitable for the purpose of a ax25 system.

It’s a Dell Vostro 220 Series/0P301D with Pentium(R) Dual-Core CPU E5200 @ 2.50GHz processor.
And 2Gb of memory.

Furthermore, I have chosen to use a sata raid controller. From Delock.
PCI Card > 4x internal SATA with RAID.
(RAID bus controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller)
Data transit 150 MB/s <-> 1.5 Gbit/s

This card can be RAID 0/1, 0+1. I have chosen to use RAID 1 (mirroring).
This has the advantage that if I use 2 disks there can always be one piece that can go up in smoke,
and the system still continues to run without data loss. Now I can change the broken HD and rebuild the RAID array. All this without data loss. Only the system will know some downtime because a sata disk is not hot swappable. (in this system). And we have to rebuild the RAID array.

I still have 4 old 80Gb drives, but I’m a little bit hesitant because these drives have been running for hours/days/months already. So I think I buy some SSD discs. I have been testing this system with Debian Stretch, and it just running fine.

I have benchmark the old HDD’s… It doesn’t look good.

Using Fio to benchmark. Random read/write performance

./fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test / 
--bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75

This will create a 4 GB file, and perform 4KB reads and writes using a 75%/25% (ie 3 reads are performed for every 1 write) split within the file, with 64 operations running at a time. The 3:1 ratio is a rough approximation of your typical database.

pth=64 --size=4G --readwrite=randrw --rwmixread=75
test: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio-2.1.10
Starting 1 process
Jobs: 1 (f=1): [m] [100.0% done] [1504KB/388KB/0KB /s] [376/97/0 iops] [eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=8223: Thu Dec 7 08:54:51 2017
read : io=3071.7MB, bw=498349B/s, iops=121, runt=6463092msec
write: io=1024.4MB, bw=166188B/s, iops=40, runt=6463092msec
cpu : usr=0.11%, sys=0.58%, ctx=1035400, majf=0, minf=6
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
issued : total=r=786347/w=262229/d=0, short=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
READ: io=3071.7MB, aggrb=486KB/s, minb=486KB/s, maxb=486KB/s, mint=6463092msec, maxt=6463092msec
WRITE: io=1024.4MB, aggrb=162KB/s, minb=162KB/s, maxb=162KB/s, mint=6463092msec, maxt=6463092msec

Disk stats (read/write):
sda: ios=782814/264536, merge=3607/1804, ticks=309674428/102480492, in_queue=412156584, util=100.00%

iops, Input/Output Operations per Second, and that’s what it’s all about. But well, this system doesn`t get a full load… I’m curious about the test with SSD disk.

Update 🙂
Yes i’m dead…my girlfriend is going to kill me, I just ordered 3 ssd discs 😉

Debian wheezy LTS

It looks like I’m going to get into trouble if I keep using Wheezy. There will probably be no security updates after May 31, 2018, any more. Maybe I should switch to Jessie. Or perhaps Stretch. There is even a newer version “Buster” (Alpha 1). I think Jessie can be a good choice.

LTS stands for Long Term Support.

However, I do not like the idea that Wheezy sees the end of his life.

mkiss: ax2: truncating oversized transmit packet!

I encountered strange behavior today. Syslog is fully spammed

Dec  2 17:05:28 gw kernel: [33263.528216] mkiss: ax2: truncating oversized transmit packet!
Dec  2 17:05:28 gw kernel: [33263.529380] mkiss: ax2: truncating oversized transmit packet!
Dec  2 17:05:28 gw kernel: [33263.530492] mkiss: ax2: truncating oversized transmit packet!
Dec  2 17:05:28 gw kernel: [33263.531606] mkiss: ax2: truncating oversized transmit packet!
Dec  2 17:05:28 gw kernel: [33263.533164] mkiss: ax2: truncating oversized transmit packet!
Dec  2 17:05:28 gw kernel: [33263.534454] mkiss: ax2: truncating oversized transmit packet!
Dec  2 17:05:28 gw kernel: [33263.535679] mkiss: ax2: truncating oversized transmit packet!
Dec  2 17:05:28 gw kernel: [33263.537071] mkiss: ax2: truncating oversized transmit packet!
Dec  2 17:05:28 gw kernel: [33263.538409] mkiss: ax2: truncating oversized transmit packet!

The main issue was that i set the mtu of ax2 to 128. I do not know why, but just don`t do it. 🙂

ax2       Link encap:AMPR AX.25  HWaddr PI1LAP-3
          inet addr:44.137.31.73  Bcast:44.137.31.95  Mask:255.255.255.224
          UP BROADCAST RUNNING  MTU:128  Metric:1
          RX packets:1267 errors:0 dropped:0 overruns:0 frame:0
          TX packets:198 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10
          RX bytes:253763 (247.8 KiB)  TX bytes:4538 (4.4 KiB)

This is the code that generates this error. (mkiss.c)

 if (len > ax->mtu) { /* Sigh, shouldn't occur BUT ... */
// translation of above: if data size of frame is GREATER than the 
// allowed MTU of ax25, generate the printk (print kernel error) below.
 - len = ax->mtu;
 printk(KERN_ERR "mkiss: %s: truncating oversized transmit packet!\n",
 ax->dev->name);
 dev->stats.tx_dropped++;
 netif_start_queue(dev);

Brian n1uro had this to say about it

It looks like this isn't a bug but a config issue on your end if I'm
reading their code correctly. You're trying to squeeze 100 litres of
water/minute through a hose that can only handle 50 litres/min so it's
telling you that it's fragmenting your frames to fit the proper MTU.

So just set your mtu to 256.

root@gw:/etc/ax25# cat axports
ax2     PI1LAP-3        19200   256     4       BBS pi8lap