Topics

Linux Disk Performance

George Sz
 

Hello,

I've been running my reception station on 64bit Linux for a couple of years now and I even upgraded my PC to a decently powerful Haswell Core i5 with 8 GBs of RAM. While Tellicast introduced a receive_buffer_size option, I'm still struggling to receive HVS data onto a hard disk. SSD reception is fine but I find it somewhat of a luxury, considering my hard disk can definitely keep up with its write speed. The problem probably lies within access times and how Tellicast behaves.

Has anybody managed to tune the Linux cache system in a way that it allows for delayed writes (or perhaps something else that works)? Or it's simply the Tellicast client that's written in a way that "breaks" this? I noticed some unwanted behavior regarding file links it's using (ie. you can't have tmp and data dirs on different disks).

If anybody has any feedback on this, it would be appreciated.

Thanks,
George

Christian Peters
 

George,

Ernst wrote a script "mvmsg" which uses a 3GB ramdisk to solve this problem. I use his script on my Linux receiver, it runs very well.
I think he will contact you in the forum for the details and provide you the latest version.

Regards,

Christian


Am 11.02.19 um 20:51 schrieb George Sz:

Hello,

I've been running my reception station on 64bit Linux for a couple of years now and I even upgraded my PC to a decently powerful Haswell Core i5 with 8 GBs of RAM. While Tellicast introduced a receive_buffer_size option, I'm still struggling to receive HVS data onto a hard disk. SSD reception is fine but I find it somewhat of a luxury, considering my hard disk can definitely keep up with its write speed. The problem probably lies within access times and how Tellicast behaves.

Has anybody managed to tune the Linux cache system in a way that it allows for delayed writes (or perhaps something else that works)? Or it's simply the Tellicast client that's written in a way that "breaks" this? I noticed some unwanted behavior regarding file links it's using (ie. you can't have tmp and data dirs on different disks).

If anybody has any feedback on this, it would be appreciated.

Thanks,
George

David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

Hello,

I've been running my reception station on 64bit Linux for a couple of years now and I even upgraded my PC to a decently powerful Haswell Core i5 with 8 GBs of RAM. While Tellicast introduced a receive_buffer_size option, I'm still struggling to receive HVS data onto a hard disk. SSD reception is fine but I find it somewhat of a luxury, considering my hard disk can definitely keep up with its write speed. The problem probably lies within access times and how Tellicast behaves.

Has anybody managed to tune the Linux cache system in a way that it allows for delayed writes (or perhaps something else that works)? Or it's simply the Tellicast client that's written in a way that "breaks" this? I noticed some unwanted behavior regarding file links it's using (ie. you can't have tmp and data dirs on different disks).

If anybody has any feedback on this, it would be appreciated.

Thanks,
George
=====================================

George,

Interestingly, the systems I've found providing the best HVS-1 and HVS-2 performance have been ones with a separate hard disk for each service, and using a hard disk (not an expensive SSD), and not using a RAMdisk (with the complications and compromises of move scripts).

I've /never/ seen zero missed & recovered packets with the single-input dual-tuner PCIe cards when running under Windows-10 with the TBS 6903 card, although Arne van Belle often gets zero lost packets with his more stable signal and Windows-7.

Tmp and received /must/ be on the same partition so that there is no physical move of the tmp file to the received location when the file is complete - it's just a change of directory entry. It's a move rather than a copy, in physical terms.

Cheers,
David
--
SatSignal Software - Quality software for you
Web: http://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv

GERARD BOON
 

Hi David,

related to George’s question and your comments how vital is the receive buffer introduced in Tellicast 2.14? I use 2.14 for HVS-1 but 12.2 for basic service as I have so far not had the courage to change my received channels init file. I receive both services from Ayecka SR1 which I know is not the most optimal way plus using a iMac which is running Windows 7 through boot camp which to all intends and purposes is a PC then but it is limited on RAM to 8GB and showing its age (Late 2008) so I do have missed packets but otherwise is very stable. 

Gerard

Ernst Lobsiger
 

George

I have studied the problem years ago. I use a 3GB RAM disk
and a simple bash script "mvmsg". I also wrote "MVMSG.CMD",
a solution for Windows, but this might look too UNIX like for
most Windows users. The problem is that the TelliCast client
cannot stand I/O-waits. This is not OS specific and shows up
as soon as you do not use the latest and greatest hardware. I
have two somewhat technical papers that explain my findings.

I can receive BAS + HVS-1 + HVS-2 and still process all OLCI
EFR images on the fly on a 10 years old Fujitsu/Siemens PC
with an Intel CoreDuo processor and 8GB RAM. My GNU/Linux
distro for EUMETCast receivers is now Devuan 2.0 ASCII amd64.
I just can't get used to systemd on a CLI EUMETCast receiver.

For a BAS + HVS-1 + HVS-2 receiver it would be best to use one
data HDD per service (per TC client!) plus one HDD (or SSD) for
the GNU/Linux system. This makes 4 HDDs while using a RAM disk
you should even manage everything with 1 current cheap HDD. I
use one very old HDD for the OS + one current 50 Euro WD Blue
1TB for data but buffered by said 3GB RAM-disk using "mvmsg".

Data is only renamed tmp when completed. That's why this must
always reside on the same file system (the same HDD partition).
If not your TC client(s) will complain about "cross-linked files".

Ernst

David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

Hi David,

related to George’s question and your comments how vital is the receive buffer introduced in Tellicast 2.14? I use 2.14 for HVS-1 but 12.2 for basic service as I have so far not had the courage to change my received channels init file. I receive both services from Ayecka SR1 which I know is not the most optimal way plus using a iMac which is running Windows 7 through boot camp which to all intends and purposes is a PC then but it is limited on RAM to 8GB and showing its age (Late 2008) so I do have missed packets but otherwise is very stable.

Gerard
==================================

Gerard,

I would recommend updating to the current version for the BS, but I can also sympathise with the "if it works, leave it" I often recommend!

I asked EUMETSAT about the buffer parameter and it appears to be mainly for the restricted Internet service. But, yes, I changed mine up to 16 MB, and noted no change. For HVS-1, I get fewer lost packets than with the dual-tuner TBS6903, but when it's very windy the faster AGC on the TBS wins out as the link margin here for HVS-1 is not as good as it should be.

The EUMETCast data is a very fast UDP stream and it's not always obvious why one PC (i.e. one motherboard, network card, etc.) which is otherwise apparently identically configured works better than another. Win-7 may be a better choice than Win-10, but there is talk on a Win-10-Lite being developed which might work even better if it has a minimum process set running. It's interesting to know how well Boot Camp works.

Cheers,
David
--
SatSignal Software - Quality software for you
Web: http://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv

GERARD BOON
 

Hi David,

Good to know and I agree with if it isn't broken principle. The tricky thing is keeping up with the vast amount of data and it has become harder to keep track what is transmitted on which channel hence I only have set up tellicast 2.14 for HVS-1 as I only needed 3 channels for now!

I can see why it is so hard keeping the FAQ up to date.

Reading about the experiences of the Linux users seems that as an OS it is more streamlined than Windows and going through old set-up posts which recommended disabling a number of Windows processes I have experienced the odd anomaly with some of the programs so I am not sure whether that advise still holds.

David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

Hi David,

Good to know and I agree with if it isn't broken principle. The tricky thing is keeping up with the vast amount of data and it has become harder to keep track what is transmitted on which channel hence I only have set up tellicast 2.14 for HVS-1 as I only needed 3 channels for now!

I can see why it is so hard keeping the FAQ up to date.

Reading about the experiences of the Linux users seems that as an OS it is more streamlined than Windows and going through old set-up posts which recommended disabling a number of Windows processes I have experienced the odd anomaly with some of the programs so I am not sure whether that advise still holds.
================================

Gerard,

Yes, a simple mapping of service to data stream and transponder would be most useful!

I asked EUMETSAT to updated their guide as Windows-10 is indeed different in what processes run or what they are called, but EUMETSAT said (fair enough) just disable the same processes. I still think an update is needed as the Windows-7 quoted in their documents is now out of support.

Windows and Linux were originally designed for different users - let's say desktop and server - broadly speaking. Of course, usage now merged - isn't every year "The year when Linux takes over the desktop"? My view is to choose what programs or applications you want to run first, and that dictates which OS you need to run. Of course, you could receive on Linux, and allow a Windows PC for processing access to some common file-store. If you look back over the group messages you may find that installing TelliCast on Linux is not as easy as double-clicking setup.exe, but there may be benefits from doing so. Be prepared for a steep learning curve unless you already have at least some smattering of Linux, and you are very comfortable with the command-line. SSH LS MV NANO mean anything to you?

Cheers,
David
--
SatSignal Software - Quality software for you
Web: http://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv

Ernst Lobsiger
 

David and Gerard

I have now installed Windows 10 about ten times on different PCs.
Not unexpected what I saw is even far less an OS for EUMETCast
than Windows 7 has been. On the other hand GNU/Linux on the Desktop
is not and probably will never be mature or easy to setup. I try
it as a Windows 7 and Office 2007 replacement and it tock me two
days to setup the CUPS printing system and to tell it that I use
A4 and not letter sized paper. I just use LXDE as a full GNOME
or KDE-Desktop is just crazy. What an OS that welcomes me with
"Let's go shopping"? Me that still use no handy or smart phone!

The idea to push GNU/Linux to the desktop also brought us "systemd"
a Windows like monster that wants to control and do everything on
it's own. This is 100% against good old UNIX tradition where you
have simple programs that are good at doing their job. That said
it's still rather easy to setup a pure CLI GNU/Linux TC receiver but
with "systemd" it seems slightly harder do get back full control.
Next GNU/Linux distros will probably not have the "ifconfig" from
net-tools anymore but use the more powerful "ip" command. That will
break the EUMETSAT receiver setup script for "smcroute" as well.
So I must confess that things get worse under GNU/Linux as well.


Cheers
Ernst

Francis Greaves
 

Hi, Ernst. Perhaps I can put my 5 eggs in here ref the Linux Desktop.
Personally I use Gentoo Linux, which us not for beginners, however Linux Mint with the Mate desktop I find just works. Even for my wife who is not technical. Adding a printer is much easier than Windows. HP printers are particularly  well supported with the HPLip software. But I have never had any probs with Epson or Lexmark.
I understand ElementaryOS is also good for those switching from Windows
Regards to all in the Group
Francis

On 14 Feb 2019 8:33 am, Ernst Lobsiger <ernst.lobsiger@...> wrote:
David and Gerard

I have now installed Windows 10 about ten times on different PCs.
Not unexpected what I saw is even far less an OS for EUMETCast
than Windows 7 has been. On the other hand GNU/Linux on the Desktop
is not and probably will never be mature or easy to setup. I try
it as a Windows 7 and Office 2007 replacement and it tock me two
days to setup the CUPS printing system and to tell it that I use
A4 and not letter sized paper. I just use LXDE as a full GNOME
or KDE-Desktop is just crazy. What an OS that welcomes me with
"Let's go shopping"? Me that still use no handy or smart phone!

The idea to push GNU/Linux to the desktop also brought us "systemd"
a Windows like monster that wants to control and do everything on
it's own. This is 100% against good old UNIX tradition where you
have simple programs that are good at doing their job. That said
it's still rather easy to setup a pure CLI GNU/Linux TC receiver but
with "systemd" it seems slightly harder do get back full control.
Next GNU/Linux distros will probably not have the "ifconfig" from
net-tools anymore but use the more powerful "ip" command. That will
break the EUMETSAT receiver setup script for "smcroute" as well.
So I must confess that things get worse under GNU/Linux as well.


Cheers
Ernst

Ernst Lobsiger
 

Francis

I have used Slackware, Suse, RedHat, CentOS, Ubuntu, Debian and
now Devuan which borrowed some portions from Gentoo that AFAIK is
still systemd free. I have 3 HP Network printers and my problem
was that I normally setup everything with locale en.US.UTF-8.
The default paper is linked to the locale you use. So I could
ask for A4 in the printer driver but my printers still said to
have no letter paper in the tray. I solved that on the CLI now.

I had no graphical GNU/Linux dektop for almost 20 years now as
I normally do scientific computing with home brew C programs.
A Windows 7 Enterprise version plus 15 Fujitsu/Siemens PCs I
"inherited" from the school I worked till 62 has been fine for
Internet, Office and some GIS stuff. But Windows 7 support stops
early 2020 and I will never pay Microsoft again. I was given now
3 Xeon and 2 I7 16GB RAM workstations with SSDs (for free :-) and
started a graphical desktop to use EUMETCastView under GNU/Linux.
My 10 years old Fujitsu/Siemens PCs still work fine as receivers.

I have installed Windows 10 Pro + LibreOffice on the two I7 PCs
now. To get my old HP 4050N and network scanning working wasn't
easy either. The only reason I still use Windows is now NMPlot a
super small free GIS from Fred Wasmer I use as a frontend for my
GNU/Linux aircraft noise calculation package that I started 1982
on a Tek 4052A. It is still in use here and gives me some money.
But my wife will also get along with GNU/Linux and desktop LXDE.

Thanks for your 5 eggs. I always like to hear from Linux users.


Cheers
Ernst

David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

Folks,

I don't think that anyone is arguing about non-technical users - their needs can likely be met with Android, iOS or Chromebook devices, but please try and keep the discussions here relevant to EUMETCast.

Thanks,
David
--
SatSignal Software - Quality software for you
Web: http://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv

Ernst Lobsiger
 

David

Sorry for getting rather off topic. The bottom line is that both Windows and GNU/Linux keep getting fatter and less apt for EUMETCast reception. This is especially true for users of PCIe cards.

Comming back to the topic of the tread for George and (potential) GNU/Linux users: I attach my current script "mvmsg" that makes older hardware shine. Use it as a starting point for your own solutions ...

Cheers
Ernst

David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

David

Sorry for getting rather off topic. The bottom line is that both Windows and GNU/Linux keep getting fatter and less apt for EUMETCast reception. This is especially true for users of PCIe cards.

Comming back to the topic of the tread for George and (potential) GNU/Linux users: I attach my current script "mvmsg" that makes older hardware shine. Use it as a starting point for your own solutions ...

Cheers
Ernst
==============================

Yes, one reason I'm looking forward to "Windows-10 Lite" (if that is real), and why I usually install the "Lite" version of Linux on my raspberry Pi cards.

Cheers,
David
--
SatSignal Software - Quality software for you
Web: http://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv

Francis Greaves
 

Morning, David, am on holiday in NewZealand, so morning here.
I did not intend 5o go off topic. Just helping anyone looking to expand their computing skills in the Linux direction which is always relevant in my opinion.
Best wishes
Francis

Sent from Nine


From: "David J Taylor via Groups.Io" <gm8arv@...>
Sent: Thursday, 14 February 2019 16:49
To: MSG-1@groups.io
Subject: Re: [MSG-1] Linux Disk Performance


David

Sorry for getting rather off topic. The bottom line is that both Windows and
GNU/Linux keep getting fatter and less apt for EUMETCast reception. This is
especially true for users of PCIe cards.

Comming back to the topic of the tread for George and (potential) GNU/Linux
users: I attach my current script "mvmsg" that makes older hardware shine.
Use it as a starting point for your own solutions ...

Cheers
Ernst
==============================

Yes, one reason I'm looking forward to "Windows-10 Lite" (if that is real),
and why I usually install the "Lite" version of Linux on my raspberry Pi
cards.

Cheers,
David
--
SatSignal Software - Quality software for you
Web: http://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv




David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

Morning, David, am on holiday in NewZealand, so morning here.
I did not intend 5o go off topic. Just helping anyone looking to expand their computing skills in the Linux direction which is always relevant in my opinion.
Best wishes
Francis

Sent from Nine
==================================

Good to know there's always someone there to help!

Enjoy your holiday!

Cheers,
David
--
SatSignal Software - Quality software for you
Web: http://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv

hb9erg.kd0hop@...
 

Good evening everyone

I hope I'm posting this question on the correct location... :-)

** My Setup **
I'm running Linux Mint 19.2, using an internal SSD (500 GB, ext4).
Tellicast client, EUMETCastView run perfectly fine using default values.

** What I'm intending **
I'd like to use my external 2TB HDD (ext4) as target for e.g. EUMETCast BAS files:
/eumetcast/bas/default

My idea is to have only the OS and EUMETCastView running on the SSD, while the data is stored on my "big" external HDD.

I named that external 2TB HDD "EUMETCast", so it appears as:
/media/ops/EUMETCast --> It's mounted as sdb1.

As described in EUMETSAT TD15, the tmp-files database AND the target MUST be on the *same* filesystem:
"During reception, the file fragments are immediately written to the temporary location on the diskusing a temporary file name and control information is held in a database, which is resident inmemory – the file database. Once a file is completely received, it is moved from the temporaryto the target location on the disk and renamed to the original filename, and the timestamp ofthe file is set to the original time in the EUMETCast platform. It is important that the temporarylocation and target location are on the same file system, otherwise the move operation will notbe possible (in Linux) or result in a copy operation (Windows) which takes more time andresources. The move is an “atomic” and fast operation because it consists of just a change inthe file allocation table - the file itself is not touched."

If it's not, I get, as expected, the following log-file "ERROR":
Invalid cross-device link
Cannot rename file "/media/ops/EUMETCast/ramdisk/data/tmp/bas/5dd156ce00e26b3d.tmp" to "/media/ops/EUMETCast/data/eumetcast/bas/default/H-000-MSG3__-MSG3_RSS____-IR_097___-000007___-201911171415-C_" (Invalid cross-device link)
** What I tried **
So I was setting up a RAM DISK, whose destination target is on my external 2TB HDD:
sudo mount -t tmpfs -o size=2048M tmpfs /media/ops/EUMETCast/ramdisk

At file cast-client-channels_bas.ini, I typed:
target_directory=/media/ops/EUMETCast/data/eumetcast/bas/default
tmp_directory=/media/ops/EUMETCast/ramdisk/data/tmp/bas

** What I hoped for **
Now that RAMDISK (used for tmp-files) AND target directory are *presumably* on the SAME filesystem, it should work.

But: it doesn't.

** My questions **
I'm new to Linux but really would like to learn more about it and get it to work.

1) What's the correct path to my external HDD that tellicast client "understoods"? Is it
a) /media/ops/EUMETCast/
b) /dev/sdb1
c) or via /dev/disk/, e.g. by-partuuid: /dev/disk/by-partuuid/4d878bfa-5680-4e32-bef4-a9d3e003286e

2) Is it SOMEHOW possible to
- have the tmp-files saved on the RAM DISK (-or- even to the internal SSD)
AND
- the target files saved on the external HDD?

Or doesn't it make sense what I'm aiming for...? :-P


Thanks very much in advance for your help!

Vy 73 de Olivier, HB9ERG, Basel

Hugo
 

Olivier,

The control information of the received files are already saved in RAM memory ( for the latest EUMETCast client), so it is not necessary to create a RAMDISK.
A RAMDISK is a file system in memory.
If the interface to the hard disk is fast enough , I can see no reason why it would not work.

Hugo

Ernst Lobsiger
 

Hi Olivier

Welcome to the small troop of amateurs that use GNU/Linux for
EUMETCast. Nice to hear that you got it working on Linux Mint.

/dev/sdb1 is a device file meaning partition 1 on your second disk

You mount /dev/sdb1 tt an appropriate mount point
(directory) in your root file system / that apparently
resides on your SSD /dev/sda? ... If you type just "mount" in
a terminal you see how it's all assebled. Your SSD may also
be partitioned in /dev/sda1 (SWAP) and /dev/sda2 / (root) ...

Your mount point seems to be /media/ops/EUMETCast
So if /dev/sdb1 is not mounted, /media/ops/EUMETCast
is just a directory on your SSD that you can use as
far as you have access rights. As soon as /dev/sdb1
is mounted here, writing to this directory means
writing to (the top most place of) your big disk.

In Linux you *MUST* have the EUMETCast tmp directory and the
final received files on the same file system (partition). In
your case everything either on SSD (which will wear out and
overfill faster than you like it ...) or on your hopefully
fast enough second HDD. So forget your idea of

sudo mount -t tmpfs -o size=2048M tmpfs /media/ops/EUMETCast/ramdisk

This makes a tmp file system in memory that you give a mount point
on your second HDD which is already mouted on your SSD. Not KISS.
A tmpfs is not even a RAM disk as expected as it swaps out data
blocks that have not been touched for some time to your SWAP device.

Just for whatever channels an entry (I made ist already shorter :-)

target_directory=/media/ops/EUMETCast/bas/data/default
tmp_directory=/media/ops/EUMETCast/bas/tmp

This should work though I have my paths much more flat
and mount the data HDD as just /srv (or /opt or /mnt)

Soon you will want to slice your data in channel directories.


Cheers
Ernst

Heiko Schellhorn
 

Hi Oliver, Ernst

Welcome to the small troop of amateurs that use GNU/Linux for
EUMETCast. Nice to hear that you got it working on Linux Mint.
As one of the non-amateurs :-) running EUMETCast (TelliCast) in the meantime for more than 14 years under Linux (just switched to Terrestrial) two additional hints for you.

First I would suggest not to mount the disk under /media/ops...
It's up to you but IMHO /media/username should be only dedicated to temporary mounted drives likes USB-Sticks etc.

Second:
As you mentioned you use an external disk mounted under /media/ops/...

External disks have sometimes the bad habit to change the device during reboot (e.g. forgotten USB-stick still plugged to the system).
So easily /dev/sdb becomes /dev/sdc

So I would suggest that you mount the external disk via /etc/fstab during boot using the UUID of the partition. So you can forget as many USB sticks as you want plugged ;-)

you'll get the UUID with

blkid -o value -s UUID /dev/sdb1

The entry in your /etc/fstab may then look like

UUID=71e540ba-697d-4229-b089-c27265d08fc9 /EUMETCast-data ext4 errors=remount-ro 0 1


Best wishes implementin your reception station.


Heiko

--
---------------------------------------------------------------------------
Dipl. Inf. Heiko Schellhorn

University of Bremen Room: NW1-U 2065
Inst. of Environmental Physics Phone: +49(0)421 218 62091
P.O. Box 33 04 40 Fax: +49(0)421 218 62070
D-28334 Bremen Mail: mailto:schell@...
Germany www:
http://www.iup.uni-bremen.de/~schell
http://www.sciamachy.de
http://www.esa-ghg-cci.org
http://www.tropomi.eu/

»In Deutschland gilt derjenige, der auf den Schmutz hinweist,
als viel gefährlicher als derjenige, der den Schmutz macht.«
- Kurt Tucholsky-

Gegen eine Dummheit, die gerade in Mode ist,
kommt keine Klugheit auf.
(Theodor Fontane)